feat(amm)!: add transaction deadlines to swap and liquidity instructions#67
feat(amm)!: add transaction deadlines to swap and liquidity instructions#67
Conversation
0x-r4bbit
force-pushed
the
feat/tx-deadline
branch
from
a210bb5 to
b834ca4
Compare
0x-r4bbit
force-pushed
the
feat/tx-deadline
branch
from
b834ca4 to
0acac8d
Compare
There was a problem hiding this comment.
Pull request overview
Adds transaction expiry (deadline) enforcement to AMM swap and liquidity instructions by requiring a clock account and rejecting execution after the provided Unix timestamp (ms), addressing replay/stale-execution risk (Issue #8).
Changes:
- Extend
amm_core::Instructionvariants (AddLiquidity / RemoveLiquidity / SwapExactInput / SwapExactOutput) withdeadline: u64and require the clock system account. - Enforce deadlines in the AMM guest entrypoints by reading
CLOCK_01_PROGRAM_ACCOUNT_IDaccount data. - Update integration tests + IDL artifacts to include the new argument and required clock account; add expired-deadline rejection tests.
Reviewed changes
Copilot reviewed 6 out of 8 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| integration_tests/tests/amm.rs | Adds deadline to instruction construction, includes clock account in messages, and adds expired-deadline tests (plus helper to advance clock). |
| integration_tests/Cargo.toml | Adds clock_core dependency for test clock account IDs. |
| artifacts/amm-idl.json | Updates IDL to include deadline args and clock account for affected instructions (but currently includes non-JSON build output). |
| amm/methods/guest/src/bin/amm.rs | Implements enforce_deadline and wires clock + deadline into relevant guest instruction handlers. |
| amm/methods/guest/Cargo.toml | Adds clock_core dependency for guest deadline enforcement. |
| amm/methods/guest/Cargo.lock | Locks new clock_core dependency. |
| amm/core/src/lib.rs | Updates instruction enum to include deadline and documents the required clock account. |
| Cargo.lock | Records workspace-level dependency resolution changes including clock_core. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
0x-r4bbit
force-pushed
the
feat/tx-deadline
branch
8 times, most recently
from
1ca82ed to
24bd918
Compare
3esmit
left a comment
3esmit
left a comment
There was a problem hiding this comment.
Add deadline on the pool initialization, filling the NewDefinition expiry gap. This PR adds deadline enforcement to AddLiquidity, RemoveLiquidity, SwapExactInput, and SwapExactOutput, but pool initialization can still execute later with no time boundary if the signed holding nonces remain unchanged. The concrete risk is stale initial pricing: a user can sign pool creation at one token ratio, the transaction can sit unsubmitted, and later execution can initialize the pool at that old ratio, leaving the first LP position exposed to immediate arbitrage. Please either add the same deadline/timestamp validity window to NewDefinition, or explicitly split pool-initialization expiry into a follow-up and avoid presenting this as complete AMM transaction-expiry coverage.
3esmit
left a comment
3esmit
left a comment
There was a problem hiding this comment.
Improve test coverage. The implementation adds a deadline to SwapExactOutput, but the new expired-deadline integration tests only cover exact-input swap, add liquidity, and remove liquidity. Please add an expired-deadline SwapExactOutput test and assert NssaError::OutOfValidityWindow so the tests prove the deadline mechanism, not just any failure.
The current PR body still describes a CLOCK_01 account and direct clock-account reads, but the diff now documents and implements timestamp validity windows on the program output with no clock account. Update the PR body before merge so integrators do not add a nonexistent account to the AMM instruction interface. |
0x-r4bbit
force-pushed
the
feat/tx-deadline
branch
from
24bd918 to
b53a40b
Compare
|
@3esmit address all of yoru comments |
All mutable AMM instructions now require a `deadline: u64` field (Unix timestamp in milliseconds). Enforcement uses the LEZ-native timestamp validity window set on ProgramOutput; the runtime rejects the transaction if the sequencer submission timestamp is at or past the deadline. BREAKING CHANGE: AddLiquidity, RemoveLiquidity, SwapExactInput, SwapExactOutput, and NewDefinition instruction variants now require a `deadline` field. Closes #8
0x-r4bbit
force-pushed
the
feat/tx-deadline
branch
from
b53a40b to
216e92d
Compare
AddLiquidity, RemoveLiquidity, SwapExactInput, and SwapExactOutput now require a
deadline: u64field (Unix timestamp in milliseconds). The guest program reads the on-chain CLOCK_01 account and panics ifclock.timestamp > deadline, preventing stale transactions from being executed. NewDefinition is excluded since it sets the initial price explicitly with fixed amounts — there is no time-sensitive price risk.BREAKING CHANGE: AddLiquidity, RemoveLiquidity, SwapExactInput, and SwapExactOutput instruction variants now require a
deadlinefield, andCLOCK_01_PROGRAM_ACCOUNT_IDmust be included as an account in each of these transactions. The clock account is populated by the LEZ clock program — a dedicated system transaction that writes the current timestamp into the clock accounts. The AMM guest reads the account data directly; there is no implicit timestamp injection from the runtime.Closes #8